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Abstract 

During the last years, large-scale simulations of realistic 
physical environments which support the interaction of 
multiple participants over the Internet have become in¬ 
creasingly available and economically significant, most 
notably in the computer gaming industry. Such sys¬ 
tems, commonly called networked virtual environments 
(NVEs), are usually based on a client-server architecture 
where for performance reasons and bandwidth restric¬ 
tions, the simulation is partially deferred to the clients. 
This inevitable architectural choice renders the simulation 
vulnerable to attacks against the semantic integrity of the 
simulation: malicious clients may attempt to compromise 
the physical and logical laws governing the simulation, or 
to alter the causality of events a posteriori. 

In this paper, we initiate the systematic study of seman¬ 
tic integrity in NVEs from a security point of view. We 
argue that naive policies to enforce semantic integrity in¬ 
volve intolerable network load, and are therefore not prac¬ 
tically feasible. We present a new semantic integrity pro¬ 
tocol based on cryptographic primitives which enables the 
server system to audit the local computations of the clients 
on demand. Our approach facilitates low network and 
CPU load, incurs reasonable engineering overhead, and 
maximally decouples the auditing process from the soft 

*The work described in this paper has been supported in part by the 
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real time constraints of the simulation. 


1 Introduction 

Interactive physically plausible simulations of artificial 
worlds have evolved from a topic of philosophical spec¬ 
ulation and science fiction into an increasingly impor¬ 
tant and highly active area of computer science. With 
the cheap availability of extensive computing power as 
well as networking bandwidth, today’s technology has in 
fact surprisingly quickly reached the point of actually im¬ 
plementing networked virtual environments EniETi with 
reasonable quality. One of the major driving forces in 
this development has been the computer gaming indus¬ 
try which has successfully developed massively multi¬ 
player online games (MMORGs) where thousands of hu¬ 
man participants interact over the Internet in artificial en¬ 
vironments with almost photo-realistic simulation qual¬ 
ity EKD. Gaming applications are the ideal playground 
for advancing NVE technology: MMORG failure sce¬ 
narios are relatively uncritical (in comparison to, say mili¬ 
tary simulations), technical features are at times more val¬ 
ued by the customers than total reliability, and, last not 
least, there are large economic interests from major in¬ 
dustrial players including Microsoft, IBM and Sony. 

The long term impact of NVE technology, however, 
will be a paradigm switch whose impact reaches far 
beyond computer gaming: it is widely expected that 
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advanced Internet services facilitating online collabora¬ 
tion, e-commerce, virtual communities, entertainment, 
medicine, design, etc. will be based on NVE technology. 
Recent special issues by the IEEE Communications Mag¬ 
azine (3 on NVE technology as well as Communications 
of the ACM 01 (on the transition of gaming technol¬ 
ogy into canonical computer science, and on interactive 
immersion in 3D graphics) reflect the rapidly increasing 
industrial interest in NVEs. 

Despite the evident industrial interest in NVE technol¬ 
ogy, academic contributions to this emerging field hitherto 
have been mostly confined to the virtual reality commu¬ 
nity. The technical issues arising in N VEs however pose 
important challenges to the state of the art in many clas¬ 
sical areas of computer science, including software en¬ 
gineering, distributed systems, databases, and also com¬ 
puter security. The goal of the current paper is to initiate 
the systematic study of security issues in NVEs and to 
present security protocols which prevent malicious par¬ 
ticipants from compromising the semantic integrity of the 
NVE. 

In order to put our technical results in perspective, we 
will first review the architecture of NVEs. 

NVE Architecture. Eollowing 1201 . a virtual environ¬ 
ment is an interactive, immersive, multi-sensory, 3 dimen¬ 
sional, synthetic environment. Typically, the participants 
of a virtual environment are represented by avatars (i.e., 
virtual characters) that can move through a realistic vir¬ 
tual world inhabited by various computer-controlled ac¬ 
tive objects. When the virtual environment is distributed 
over a number of hosts, we speak of a networked virtual 
environment (NVE). We can naturally distinguish two 
crucial purposes of networking in NVEs: 

• Clustering: Since the computational load of a large- 
scale virtual environment is enormous, the simula¬ 
tion needs to be distributed over a number of com¬ 
puters. To this aim, a relatively small number of 
nodes is interconnected within an enclosed cluster. 
To the outside world, such a cluster ideally mimics 
the behavior of a single machine (which we shall call 
StateServer later on.) Since all resources within the 
cluster are solely dedicated to the NVE, we will as¬ 
sume that they are mutually trusted. Consequently, 


clustering does not directly affect the security of the 
NVE. 

• Remote Access: Networking is an obvious necessity 
as soon as a number of geographically dispersed per¬ 
sons or client computers have to interact within the 
same virtual environment. In this case however, nei¬ 
ther the connection to the server system nor the client 
itself sit under control of the NVE system. Conse¬ 
quently, NVEs with remote access not only have to 
cope with the deficits of the underlying networking 
infrastructure (long transmission times and frequent 
packet loss, see ca for an overview), but also with 
malicious clients attacking the NVE . 

There are two principal architectures to enable remote 
access, namely peer-to-peer and client-server. In this pa¬ 
per we are only concerned with remote access NVEs 
which are based on the more important client-server 
model 1121 In a client-server NVE architecture, the au¬ 
thoritative and central version of the state of the NVE 
is maintained by the server system StateServer. The 
clients Clienti,..., Client^ have private and limited ac¬ 
cess to the central state of the NVE. 

Each time Clienti wants to update the shared state 
of the NVE, it has to send a corresponding request to 
StateServer. StateServer checks whether the requested 
actions are compliant to the rules of the NVE. If this is 
the case, StateServer sends to Clienti an authoritative 
state update message that contains (as acknowledgement) 
the requested state update of Clienti as well as all changes 
to the central state that occurred since the last update mes¬ 
sage was sent to Clienti. Einally, Clienti updates its local 
state according to the answer received from the server sys¬ 
tem. 

By a client cycle we shall understand one complete 
turnaround of the client state as described above, i.e., the 
compound procedure which starts with the computation 
of the update request by Clienti and ends with the client 
state update according to the server response. 

Security and Semantic Integrity. In NVEs facilitating 
remote access, a large number of potentially anonymous 
participants interact with the server using client software 
which can be modified by malicious participants. Conse¬ 
quently, any security assessment of NVEs must assume 
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that all clients are untrusted. In Section |2] we provide a 
systematic taxonomy of attacks against NVEs. We ar¬ 
gue that in addition to the classical security issues of net¬ 
worked systems, NVEs can be affected by attacks against 
their semantic integrity: A malicious client may attempt 
to compromise the physical and logical laws governing 
the simulation, or to alter the causality of events a pos¬ 
teriori. Such attacks have been repeatedly reported for 
MMORG game applications, yet are rarely found in the 
academic literature. Semantic attacks evidently repre¬ 
sent enormous risks for the commercial N VE applications 
mentioned above. 

Instead of implementing the centralized simulation 
model outlined previously, NVEs typically employ a dis¬ 
tributed simulation model where the server only maintains 
a simplified (“abstract”) global state, whereas the detailed 
simulation (e.g., graphical rendering, or extrapolation of 
events) is partially deferred to the clients. Such an ap¬ 
proach reduces the processing power requirements for up¬ 
dating the state maintained at the server and reduces the 
bandwidth necessary to exchange state updates. However, 
the semantic gap between the server and the clients can 
be exploited by malicious clients. Such a client can suc¬ 
cessfully submit spurious updates, i.e., updates that are 
consistent with the rules of the NVE on the abstract level, 
but violate the NVE semantics on the concrete level. 

Eor example, in many entertainment NVEs, the server 
system is only maintaining rough geometric representa¬ 
tions of physical objects in the simulated world. Conse¬ 
quently, the server-side collision detection is much more 
efficient but is also more permissive, while the clients are 
responsible for implementing the collision detection at a 
detailed level. A malicious client can exploit this situa¬ 
tion by moving an object along a path that is correct with 
respect to the rough abstract state but is incorrect with 
respect to the concrete state. Figure Q] illustrates this sit¬ 
uation with a simple example where an object has to be 
moved through a tunnel: Since the server system main¬ 
tains an abstracted geometrically simple view of the world 
(where the boundaries in this case are obtained from con¬ 
vex hulls of certain anchor points), the client is able to 
claim that the object can actually be moved through the 
tunnel. Since the inconsistent update will be accepted by 
the server, the malicious client has successfully broken 
the rules of the NVE. 

Although the given geometric example may appear 



Figure 1: Example of a semantic attack. 

simplistic, every reasonably powerful abstraction will in¬ 
evitably result in information loss, enabling malicious 
clients to submit spurious updates. 

Engineering requirements. Performance and scalabil¬ 
ity constraints require large-scale NVEs to employ an ar¬ 
chitecture where significant computations are performed 
at the client side; see (m for a comprehensive overview. 
More specifically, any NVE implementation should sat¬ 
isfy the following two requirements: 

• Autonomous Clients: The client of an NVE must 
be autonomous to provide a fluent simulation. In 
particular, the client has to extrapolate missing in¬ 
formation and to interpolate between discrete client 
cycles. For example, the client is responsible for ex¬ 
trapolating the current position of an object if a posi¬ 
tion update is lost due to the deficits of the network 
connection. 

• Abstracted Central State: As argued above, 
StateServer can only maintain the abstracted infor¬ 
mation which is necessary to coordinate the clients, 
while the clients utilize a more concrete version of 
the state. In general, the state server has a more “ab¬ 
stract” view of the world than the clients. 

A useful security solution for NVEs must be designed to 
meet the following requirements in addition: 

• Minimal and Scalable Resource Overhead: The 

overhead caused by the security solution should be 
as small as possible and scale well with respect to the 
number of participants and the level of security to be 
enforced. While this sounds like an obvious require¬ 
ment, we want to stress that NVEs produce heavy 
CPU and network loads. Therefore, any approach 
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which causes significant CPU or network overhead 
at the client- or sever-side is impractical. 

• Minimal Quality of Service Requirements. A se¬ 
curity solution should utilize unreliable network ser¬ 
vices for as many messages as possible. Only a few 
important messages should require timely and reli¬ 
able send operations. 

• Minimal Engineering Overhead: NVEs are com¬ 
plex software systems which usually consist of mul¬ 
tiple large software packages. Thus, it is often infea¬ 
sible to modify an existing NVE to meet strict se¬ 
curity requirements. Because of the growing legacy 
code which is used to build new NVEs, a security 
solution should be as independent as possible from 
the simulation and should only affect small portions 
of the code. 

Technical contrihution. The main technical contribu¬ 
tion of this paper is a set of protocols which allow to main¬ 
tain the states of the clients and the server consistently 
and securely, even in the presence of maliciously modi¬ 
fied clients. The approach is based on an efficient audit 
procedure that is performed repeatedly and randomly on 
the NVE clients. During the audit process, it is verified 
whether the concrete state updates performed by the client 
in a specific time frame are valid according to the NVE 
semantics. The solution meets all above stated require¬ 
ments: 

• The protocols enforce semantic integrity on the 
NVE clients, while allowing a central abstracted 
state and autonomous clients. 

• The solution incurs very low additional network traf¬ 
fic, and requires the transmission of complete client 
states over the network only during the audit process. 
More precisely, our solution requires only a few ad¬ 
ditional bytes per client cycle which is a negligible 
quantity in comparison to the other messages in the 
client cycle. The security overhead consists solely 
of a Messages Authentication Code which is consid¬ 
ered secure at a size of 16 bytes. On the other hand, a 
modern MMORG requires roughly one kilobyte per 
client and cycle. Note that with thousands of clients, 
bandwidth is a bottleneck mainly at the server side. 


• Our solution uses reliable and time critical network 
transmissions only for a few small messages. All 
other messages, in particular the complete audit pro¬ 
cess, can be implemented solely using unreliable 
send operations. 

• The audit process is completely independent of the 
(time critical) simulation, and will in general not af¬ 
fect the smoothness of the simulation for all but pos¬ 
sibly the audited party. 

• The protocol is designed as to be integrated into ex¬ 
isting middleware and clients with tolerable over¬ 
head. 

Related Work on Security. Audit trails were success¬ 
fully applied in electronic commerce applications (e.g., 
see 1131 1. An audit trail enables a special party, called au¬ 
ditor, to verify the correctness of previous transactions. 
The audit trail can either be stored at the client or the 
server. In any case, the audit information must be pro¬ 
tected from modifications. Bellare and Yee O identi¬ 
fied/orwarii security as the key security property for au¬ 
dit trails: even if an attacker completely compromises the 
auditing system, he should not be able to forge audit in¬ 
formation referring to the past. Implementations of secure 
audit and logging facilities can be found in 11611151 1^. 

The protocols described in this paper follow the prin¬ 
ciples of audit trails, but account for the specific partic¬ 
ularities of NVE environments. Most importantly, our 
solution incurs a minimal network traffic overhead, while 
retaining its security. In fact, a direct adoption of classical 
audit trails to the NVE scenario would inflict a large load 
on the network, as the concrete state updates of all clients 
must be verified. In our solution, the audit information 
is stored at the client side and sent to the auditor on re¬ 
quest. The client only “commits” itself to a status update 
by sending a short message to the server, which cannot be 
altered later. 

Only a few papers have dealt directly with security in 
online games. Baughman and Levine Q concentrated on 
peer to peer multiplayer games, while we consider client 
server architectures of large-scale online games. Yan and 
Choi 12111221 gave a taxonomy of security issues in on¬ 
line games and a case study on security of online bridge 
gaming. Davis im points out the importance of security 
in online games from a business perspective. 
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The rest of this paper is organized as follows: In Sec- 
tion|2]we provide a systematic threat analysis for NVEs, 
whereas Section|3provides a description of the basic state 
update mechanism performed by traditional NVEs which 
maintain a central abstracted state. Section provides a 
detailed technical description of our proposed security so¬ 
lution. Einally, a summary and outlook on future research 
can be found in Section]^ 

2 Threat Analysis 

In the first NVEs to be deployed, the users belonged 
to well-defined groups whose NVE-clients were trusted. 
However, as large-scale NVEs with untrusted and dis¬ 
persed participants are becoming more popular, the se¬ 
curity of NVEs becomes an eminent issue. The security 
threats occurring in the context of an NVE with untrusted 
participants can be classified as follows: 

1. System Security Attacks: There are a number of 
classical security problems associated with NVEs, 
such as authentication, payment, or host security. 
These security issues have been widely studied 0 

d. 

2. Semantic Subversion: The participants of an NVE 
can interact in the virtual environment according to 
a set of rules. The enforcement of these rules is of 
crucial importance for all honest participants. We 
call attacks targeted at circumventing or subverting 
these rules semantic attacks. 

(a) Semantic Integrity Violation: Attacks in this 
category attempt to violate the physical and 
logical laws of the NVE without detection by 
the server. All attacks in this class involve ma¬ 
liciously modified software on the client side 
and come in two flavors: 

i. Rule Corruption: The malicious client 
attempts to modify the simulation in a way 
that is illegal but plausible to the server 
system. 

ii. Causality Alteration: The malicious 
client attempts to withdraw previous ac¬ 
tions to obtain unfair advantages, i.e., the 
client attempts to “rewrite its history”. 


(b) Client Amplification: In this case, the client 
employs special software to achieve capabil¬ 
ities to exploit the possibilities of the NVE 
in an unintended manner. During such an at¬ 
tack, the externally observable behavior of the 
amplified client is not reliably distinguishable 
from the behavior of a honest client. Amplifi¬ 
cation attacks contain the following two main 
categories: 

i. Sniffing: The malicious client exposes in¬ 
formation which has to be downloaded for 
technical reasons but is not intended to be 
observable immediately. 

ii. Agents: The malicious client enhances the 
natural capabilities of the human partici¬ 
pant, e.g., by logging and evaluating pre¬ 
vious events systematically, or by partially 
replacing the human participant with auto¬ 
mated search strategies. 

3. Metastrategies: Attacks in this category are com¬ 
pliant with the NVE and do not involve software 
modifications. They exploit principal vulnerabili¬ 
ties present in the NVE, e.g., collusive collaboration 
of human participants, or mobbing of fellow partici¬ 
pants. 

Note that system security attacks are targeted against the 
server systems, while all other attack groups identified in 
this section describe exploits which involve the client side 
only. 

System security attacks are exploits that do not involve 
specific properties of NVEs and therefore they are not in 
the scope of this paper. On the other extreme. Metastrate¬ 
gies cannot be coped with by technical means. Conse¬ 
quently, the focus of this paper is on Semantic Subversion 
Attacks; these attacks are further subdivided into the cat¬ 
egories Semantic Integrity Violation and Client Amplifi¬ 
cation. The latter cannot be handled in a rigorous way, 
but are amenable to statistical detection and countermea¬ 
sures similar to intrusion detection systems. Thus, we 
have identified Semantic Integrity Violation as the main 
NVE-specific class of attacks which needs to be treated 
at the protocol level. The protocols presented in this pa¬ 
per consider both rule corruption and causality alteration 
attacks. To do so, the protocols enforce the following two 
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conditions on the client behavior; 

• Rule Compliance: Each client is only allowed to 
act in accordance with the rules of the NVE. This 
prevents rule corruption. 

• Action Commitments: Critical actions initiated by 
the client must be executed in an unrevocable and 
undeniable manner. Consequently, clients are not 
allowed to choose an alternative history of actions 
once they obtain more information in the future. This 
condition prevents causality alteration. 

3 Unsecured Client Cycle 

In this section, we review the state update mechanism 
that is commonly implemented in NVEs that maintain 
a central abstract state. We write ASTATE to denote the 
centrally maintained and abstracted state. The portion 
of ASTATE which is accessible to Client^ is denoted by 
ASTATE[Clienti] (this portion depends on the spatial po¬ 
sition of Client^ in the simulated world). Clients have to 
map these abstracted states to concrete ones. Given an 
abstract state s, we use 7(5) to denote the set of possi¬ 
ble concretizations. Eurthermore, if S' is a concrete state, 
then a{S) is the unique abstract state which corresponds 
to S. The pair a()/j{) can be naturally viewed as a Galois 
connection between the set of abstract and concrete states 
ITOl . i.e., S G 7(a(S)) and s = a{X) for any X G 7(5). 

When connecting to the NVE, Clienti receives a con¬ 
crete state S G 7(ASTATE[Clienti]) to initialize its local 
state STATE[Clienti]. Erom this point on, Clienti main¬ 
tains and updates STATE[Clienti] locally. 

If Clients wishes to change its state, it has to inform 
the StateServer in order to update the central NVE-state 
ASTATE. Eor this purpose. Client^ computes a state up¬ 
date in the form of a compact description A of the dif¬ 
ference between the current state STATE[Clienti]j and the 
intended next state; we call A a diff. Given a state S and a 
diff A between S and S', we denote the application of A 
to S' by 5" = 5 ffl A. Note that A will typically be small 
compared to the state descriptions S if the NVE performs 
a hne-grained simulation of the virtual world. 

In the following, we will apply a() and 7 () not only 
to states, but also to diffs. In particular, we use a(A) to 
denote the abstraction of a diff. If S' = S ffl A holds. 


then we require that a(S') = Q!(S) ffl Q!(A) is also true. 
Eurthermore, we use 7 (S, i5) to denote the concretization 
of an abstract diff 6 relative to a concrete state S. More 
precisely, if S' = S ffl A, then A G 7 (S, a(A)) and for 
all A' G 7 (S, q;(A)), we get a(S ffl A') = a(S'). 

One client cycle consists of the following steps: The 
client sends an abstraction of A, denoted by 5 = q;(A), 
to StateServer, which evaluates the semantics of the up¬ 
date. Now, two cases can happen; 

• If (5 is allowed with respect to the semantics 
of the NVE, then StateServer responds with a 
S' that contains all changes intended by Client 
together with state updates performed by other 
clients present in the NVE. Upon receipt of 
S', Client^ computes a concretization A' G 
7(STATE[Clienti], (5') and updates its own state by 
computing STATE[Clienti](^;^ = STATE[Clienti]j ffl 
A'. 

• If (5 is not consistent with the semantics of the NVE, 
the server refuses to apply the update. This can hap¬ 
pen if Clients tries to do something impossible, such 
as opening a locked door. Moreover, inconsistencies 
can be caused by synchronization and communica¬ 
tion errors (e.g., packet loss of the underlying net¬ 
work). In this case, the StateServer responds with 
a state update S' which only contains the states up¬ 
dates of other clients. 

If the clients behave according to the NVE specihca- 
tion, this protocol suffices to consistently maintain both 
the state of the clients and the server. However, if mali¬ 
cious clients participate in the simulation, this protocol is 
susceptible to semantic integrity violation as described in 
Section^ StateServer is only able to check whether the 
abstract state updates S — a(A) are consistent with its 
abstract state. A malicious Client can make an inconsis¬ 
tent state change A whose abstraction 5 is consistent with 
the NVE rules. 

In the next section, we show how to amend the basic 
state update protocol described above with cryptographic 
mechanisms in order to prevent semantic integrity viola¬ 
tion attacks. 


6 


4 A Secure Semantic Integrity Pro¬ 
tocol 

In this section, we describe a protocol to enforce semantic 
integrity, which satisfies all requirements established in 
Section m Our approach is based on an audit procedure, 
which is performed by a dedicated server, namely the 
AuditServer. During each client cycle, the client sends a 
piece of evidence (containing a MAC of the applied con¬ 
crete state update) as action commitment to AuditServer. 
Note that our security model assumes that AuditServer is 
fully trusted, which implies that a client is unable to al¬ 
ter past action commitments. When auditing is required, 
AuditServer asks a Ciient for a sequence of concrete 
state updates for a specific time frame. Based on this in¬ 
formation, AuditServer simulates the requested segment 
of the Ciient computation and checks its compliance to 
the NVE rules. In addition, AuditServer checks whether 
the received concrete state updates match the action com¬ 
mitments received in the past. If both checks pass, the 
client is considered honest. 

Audits are initiated according to a strategy determined 
by the server, which is unpredictable for the client. For ex¬ 
ample AuditServer might choose clients for auditing in a 
completely random fashion or audit “on demand” when¬ 
ever statistical evidence suggests cheating. However, it is 
important for the security of the NVE that the clients can¬ 
not predict the time when AuditServer invokes the (next) 
audit protocol. 

The auditing process is organized in terms of audit cy¬ 
cles, where each audit cycle consists of exactly I client cy¬ 
cles. At each ^th client cycle, a new audit cycle is started. 
At the beginning of each audit cycle, the client sends a 
MAC of the concrete full state as action commitment to 
AuditServer. As this MAC may be costly to compute be¬ 
cause of the large state description, this message has to 
arrive only within the current audit cycle (i.e., within the 
next I client cycles). In addition, as noted above, the client 
sends an action commitment of the applied concrete diff 
during each client cycle; as the diff is usually small, we 
require that this message arrives at AuditServer during 
the same client cycle. 

In this paper, we assume for simplicity that I is a 
system-wide announced and agreed on parameter. How¬ 
ever, it is possible to customize I for each client while 


the simulation is running. The parameter I essentially de¬ 
termines how far back into the past auditing is possible. 
Consequently, the probability of successful cheating de¬ 
creases with both the parameter I and the frequency of the 
audit procedure. In particular, we shall see that there is a 
trade-off between the probability for successful cheating 
and the required additional network bandwidth. 

While StateServer only keeps the current abstracted 
central state, the clients do not only maintain their current 
concrete state but also retain a history of previous states 
in a local buffer, containing up to 3 full states and 2,1 diffs. 
During the audit process, AuditServer requires Client to 
prove that its actions during the last two completely fin¬ 
ished audit cycles and the current audit cycle are compli¬ 
ant to the rules of the NVE. To do so, the Client has to 
retain a copy of the complete state at the beginning of each 
new audit cycle together with diffs between the states of 
intermediate client cycles. All buffer content older than 
three audit cycles on the client side can be deleted safely. 

More precisely, the buffer describes a sliding window 
which contains the state history of the last 2Z -f 1 to ?>l 
client cycles, i.e., the last two full audit cycles and the 
current one. The sliding window which is maintained at 
client cycle fg > 2^ contains the states St^, , Stg as 

well as all the intermediate diffs ..., where 


t 


a 


i 


2 1 . 


( 1 ) 


Thus ta denotes the expiration time for client side audit 
information. In addition to the history of states, the client 
stores all messages received from the server within the 
time interval determined by the sliding window. 

Figures El, b, and c show the gradual change of the 
buffer of one specific client. These figures illustrate the 
buffer contents at client cycles 7l-\-l,7l-\-2, and 7Z -f 3 = 
81, respectively. The symbol • represents a fully saved 
state, whereas ▲ represents a concrete diff, both saved at 
the client. On the other hand, o and A represent action 
commitments of full states and diffs which are available 
at the AuditServer. 

As seen in Figure|2l at most three fully saved states are 
retained at any given time; the scope of an audit process 
covers at most three audit cycles (see Figure |2j)). Once 
a new audit cycle is completed, the information about an 
earlier audit cycle can be discarded (see Figure El) 


7 





Protocol Description. Secure integrity enforcement is 
performed by three protocols Initialize, StatusUpdate and 
Full state Audit. The protocol Initialize is performed whenever 

Dill a client wants to join the NVE, whereas StatusUpdate 

Full state action executed at each client cycle (i.e., whenever a client 

commitment available wishes to change its State). Finally, Aurf/f implements the 
availaUe°" ‘^°™““*“®“'auditing mechanism. We assume that a client leaving the 


Audited history 


Figure 2: The ’’sliding window”. 


Crucial to the correctness of the audit process is the 
enforcement of the timing conditions for the action com¬ 
mitments. The action commitment of a diff must arrive 
within the current client cycle, whereas action commit¬ 
ments of full states must be available only when the cur¬ 
rent audit cycle is completed. In Figure|2]the action com¬ 
mitments (represented by A) for diffs are available at the 
AuditServer immediately. In contrast, the action com¬ 
mitment o for the full state 71 becomes available when the 
system enters state 81. 

Note that the late availability of the full state action 
commitment messages requires the audit process to audit 
at least two full audit cycles, as otherwise the MAC (and 
thus also the semantic integrity) of the intermediate state 
, which serves as possible future audit starting point, 
cannot be verified. In contrast, the protocols can easily be 
adapted in such a way that more audit cycles are verified 
during each invocation of the audit protocol. However, 
for the sake of brevity, we present the protocols for the 
simplest case of auditing at most three audit cycles. 

If Client is audited, it has to send the contents of the 
current sliding window (i.e., the state information and cor¬ 
responding state server messages) to AuditServer. First, 
AuditServer checks whether the received state informa¬ 
tion machetes the action commitments received previ¬ 
ously. Second, AuditServer checks whether the client 
computation is compliant to the rules of the NVE by sim¬ 
ulating the client. The audit results in a positive verdict if 
and only if both checks succeed. 


NVE performs an ordinary status update, where the diff 
encodes the intention to leave the NVE. 

For the sake of simplicity, we present the protocol for 
a single client Client that interacts with StateServer and 
AuditServer. For multiple clients, the protocol is pro¬ 
cessed asynchronously in parallel. Sending a message 
unreliably will be denoted by Sending a message re¬ 
liably that must arrive before the next f-th client cycle is 
initiated, will be denoted by Unreliable messages 
may be dropped or delivered with delay. However, we 
assume that no packet corruption occurs. 

In the protocols we use a Message Authentication Code 
(MAC) as cryptographic primitive. The tagging algo¬ 
rithm, which takes a message m and a key k and pro¬ 
duces a MAC t, is denoted by f = MAC(fc, m), whereas 
the verification algorithm is written as Verijy{k,m,t) = 
{true, false}. We write M = AuthMsg{m, CWenl, k) 
as an abbreviation for m || MAC(fc, m || Client), where || 
denotes string concatenation. Furthermore, we will de¬ 
note with and the two parts of the message M, 
i.e., = m and = MAC(fc, m || Client). For 

the sake of simplicity we will abbreviate STATE[Client]( 
with St. 

The protocols use two different MAC keys: 
^StateServer mutually agreed between the state 
server and the audit server and is used to authenticate 
status updates sent from StateServer to Client. The 
MAC enables AuditServer to check whether a cheating 
Client has passed modified status update messages to 
the AuditServer. The key fcQ|i 0 |-|t is agreed between 
Client and AuditServer and is used to authenticate 
action commitments sent to AuditServer during each 
client cycle. 

In the following, we describe each protocol in detail: 


Initialize: This protocol initializes the state of a Client 
wishing to join the NVE (see Figure^- 

Upon opening a connection to StateServer, the client 
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1. Client and AuditServer exchange a MAC session key fcQ|i 0 |-||- 

2 . Client initializes t := 0 and sends an initialization request to StateServer. 

3 . StateServer chooses S e 7(ASTATE[Client]) 

4. StateServer ^ Client : Mq ■= S || no, Client) 

5. Client sets So ■= S 

6. Client AuditServer : Qo := MAC(fcQ|igp(, So) 


Figure 3: Protocol Initialize 


1 . Client computes a desired status change At+i and its abstraction Jt+i = Q;(At+i) 

2. Client ^ StateServer: 5t+i 

3. Upon receiving 6t+i, StateServer computes a new and updates its central state ASTATE accordingly 

4. StateServer ^ Client : Mt+i '■= ^“^/^■^■^^(fcstateServer’ ^t+t II Client) 

5. Client chooses Aj_|_]^ S l{St, i^t+i) computes St+^ = ffl A'+i 

6 . Client stores AJ^]^ 

7. Client AuditServer: Dt+i ■= MAC(fcQ|igpj, AJ^^) 

8 . Client increments t 

9. if f mod / = 0 


(a) Client deletes all Aj_j with 2 / < i < 3/ as well as the full state Stsi (if t > 31). 

(b) Client stores St and starts to compute Qt := MAC(fcQ|ig|-|j., St). 

(c) After computation of Qt, Client AuditServer : Qt. 


Figure 4: Protocol StatusUpdate 
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1. AuditServer ^ Client : audit\\tQ 

2. Client computes ta = ~ 2j Z 

3. Client ^ AuditServer: St^ II II... II II M,„+i II... II Mt, 

4. AuditServer computes ffl ^[+1 for i = ta, • • ■, io — 1 where St^ = St^ 

5. For alH = ta + 1, ■ • ■, fo, AuditServer checks whether A' is chosen from 7 (S'i, <5') compliant to the rules of the 
NVE, where 5[ is taken from the message Mi 

6. For alH = ta + 1,.. ■, to, AuditServer checks whether 

(a) Vfenyy(fc 3 (g(g 3 g|.ygp || Client, M^) = true and 

(b) yen)T(fcQ||gnt,A',A) =TRUE 

7. AuditServer checks whether Verify{kQ^^Q^^, St^, Qt^) = true and Verify{kQ\^Q^^, St^+i, Qt^+i) = true. 

If ta = 0, Client ^ AuditServer : and AuditServer checks f'en;^(fc 3 jgjg 3 g|.ygp So, ||Client) = 

TRUE. 

8. AuditServer accepts the computations of Client if and only if all tests in steps|3to0passed. 


Figure 5: Protocol AurfiY 


receives the relevant status information together with a 
randomly generated nounce uq and a MAC of the mes¬ 
sage. At this point the state server transmits a concrete 
state S £ 7(ASTATE[Client]) to the client. The client ini¬ 
tializes its local state S'o with S. Note that, this is the 
only point, besides the audit procedure, where a concrete 
state is transmitted. Finally, the client sends as evidence 
a MAC of its state So reliably to the audit server; as the 
MAC of the concrete state may be costly to compute, we 
only require that this sending process is completed before 
the hh client cycle is initiated. 

StatusUpdate: After initialization, the client uses this 
protocol to update its local state in each client cycle to 
reflect actions of the client itself, of other clients, and the 
state server. Formally, the protocol is shown in Figure 0] 
Suppose the client is in state St and wants to change 
its state according to the diff Aj+i. To initiate the up¬ 
date protocol, the client sends an abstracted diff 5t+i — 
a(At+i) to StateServer. The server checks whether 
this request is valid and consistent with the current cen¬ 
tral NVE state ASTATE and computes a new update de¬ 


scription This update description might differ from 
5t+i since it has to reflect changes of other clients and the 
server itself; however, if ^*+1 is legitimate with respect 
to the NVE semantics, S'tj^^ contains the state changes of 
5t+i. If (5t+i violates the semantic integrity, 5'tj^i only 
contains the state updates of the other clients but not 5t+i 
(or at most those actions in that are consistent). The 
StateServer updates its centrally managed state ASTATE 
according to 5'tj^i and sends 5'tj^i back to the client, to¬ 
gether with a MAC and an incremented nounce (steps 1-4 
of the protocol). 

The client now computes a concrete state update 
A;+i e 7(5 u<5^+i) and applies it to St to enter the next 
state St+i = 5”* ffl ^'t+i - Einally the client sends a MAC 
of the concrete diff AJ^j^ as action commitment reliably 
to the AuditServer before the next client cycle is started 
(this message is denoted by Di). Additionally, at the be¬ 
ginning of each audit cycle, the client sends a MAC of its 
full state to AuditServer; this message can be sent unre¬ 
liably and must arrive within the current audit cycle (i.e., 
within the next I client cycles); this message is denoted by 
Qi (steps 5-8 in the protocol). 
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For audit purposes, the client saves all information as 
evidence that is necessary for the audit server to simu¬ 
late its computations. More precisely, at the beginning of 
each audit cycle, the client saves its full state; in inter¬ 
mediate client cycles, the client only retains diffs to the 
previous state. In addition, the client saves all messages 
Mi received from the state server. Finally, all outdated 
audit information (i.e., the fully saved state, all diffs and 
messages belonging to the third-last audit cycle) can be 
removed (step 9 in the protocol). 

Audit-. During the audit protocol, AuditServer vali¬ 
dates the computations of one Client. In particular, 
AuditServer checks whether the client can present con¬ 
crete state updates that match the action commitments re¬ 
ceived so far and are consistent with the NVE rules; see 
Figure 13 

The auditing protocol is initiated by an audit message 
sent to the Client during client cycle An audit can be 
initiated at any client cycle fo > 2Z. The client first com¬ 
putes the starting point ta of the audit according to equa¬ 
tion m. The client then sends the concrete state St^ as 
well as all diffs A' and messages Mi for ta + 1 < i < to 
to the AuditServer (steps 1-3 of the protocol). Finally, the 
audit server checks, using the action commitment mes¬ 
sages Di and Qi submitted by the client before, whether 
the client adhered to the NVE semantics. In particular, 
the audit server checks 

• whether all A' are suitable concretizations of 5' sent 
by the state server in message Mi (step 5), 

• whether all state server messages Mi (ta + ^ < i < 
to) are unmodified (step 6a) and 

• whether all action commitment messages submitted 
by the client beforehand are valid, in particular the 
AuditServer checks 

- the MACs on the messages Di, ta + l < i < to, 
(step 6b) and 

- the MACs of the full states and con¬ 

tained in the messages and Qt^^+i (step 7). 
Note that these messages are already available 
to the audit server if the timing conditions of 
the StatusUpdate protocol are enforced. 


• If the first audit cycle is to be audited (ta = 
0), then Client is required to present = 

MAC(fcgjgjggg|.ygp S'ollClient) to AuditServer 
additionally to prove that the initial state So has been 
authorized by the StateServer (step 7). 

If all checks pass, the client is considered honest (step 8). 

Security. Our protocols enforce rule compliance be¬ 
cause in each client cycle the client is committing to its 
concrete diff A'. In addition, the client “commits” to its 
concrete state St in each Z-th client cycle. After this in¬ 
formation arrived at AuditServer, the client cannot cheat 
about its past states (in theory it is possible for a malicious 
client to send a MAC of an incorrect state in message 
Qt, but this would be noticed during the audit process). 
The audit server is thus able to fully simulate and vali¬ 
date the computations of the client. The unforgeability 
of the MAC implies that the client cannot alter its cho¬ 
sen state transitions a posteriori. Eurthermore, if the tim¬ 
ing conditions are enforced (i.e., the network delivers all 
-w-messages reliably in time) the protocols do not allow 
causality alteration, as the MAC must arrive at the audit 
server within the current client cycle. 

Computational Overhead. The protocol can be imple¬ 
mented in a very resource efficient manner: The Sta¬ 
tusUpdate protocol requires only a few MAC computa¬ 
tions over relatively small amounts of data. The MAC 
computation over the complete state of a client can be pro¬ 
cessed in background during the I client cycles of an audit 
cycle. Moreover, only the MACs are additionally trans¬ 
mitted over the network. 

In contrast, the Audit protocol is much more data in¬ 
tensive and involves a complete re-simulation of the client 
computations. However, the execution of the Audit proto¬ 
col is not time critical and can be delegated to a specific 
server, namely the AuditServer. Therefore, it does not 
cause resource overhead at the StateServer. The degree 
of confidence in the computations of the clients can be 
enhanced by increasing the number of audit servers and 
thereby increasing the number of Audit protocol execu¬ 
tions. 

In most application scenarios, the limiting resource for 
increasing the probability that a client cycle is audited 
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is the bandwidth B which is available for auditing. A 
closer analysis shows that this probability is proportional 
to where |A| is the maximum size of concrete 

diffs and \M\ is the maximum size of authorized state 
server messages. In general, the memory requirements 
of the client are not a limitation since the client can buffer 
the history on a hard disk. 

To integrate our protocol into an N VE system, one has 
to implement the protocol logic, add the computation of 
the MACs at the state server and the client, and imple¬ 
ment the audit server. It should be possible to implement 
the audit server by mainly reusing client code since the 
audit server is simulating the client computations. The 
biggest problem in implementing the protocol will likely 
be the creation of copies of the complete client state in a 
timely manner, as required at the beginning of each audit 
cycle. However, all remaining parts of the protocol can be 
implemented in a straight forward manner. 


5 Conclusion and Future Work 

In this paper, we have argued that networked virtual en¬ 
vironments are an emerging network technology which 
has not been subject to rigorous security investigations. 
We have identified semantic integrity as a core security 
problem in NVEs. Untrusted and malicious clients may 
utilize the fact that the central NVE server can—due to 
the limited computing power and the deficits of the net¬ 
work connection—only maintain an abstracted version of 
the NVE state. To overcome this problem, we have intro¬ 
duced a new audit trail mechanism which is able to verify 
the compliance of the client computation. Although we 
allow autonomous clients, our protocols assure that regu¬ 
larly cheating clients will be identified with a high proba¬ 
bility. The audit mechanism proposed in this paper can be 
integrated seamlessly into current NVE architectures and 
inflicts little engineering and resource overhead. We are 
currently working on formal security proofs for our proto¬ 
cols. The protocols presented here will be integrated into 
SYNEIGHT ITtI . a new middleware for NVEs which is 
developed by our group. A detailed description of the 
SYNEIGHT middleware will be given in future work. 
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